home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Skunkware 5
/
Skunkware 5.iso
/
man
/
cat.1
/
xconq.1
< prev
next >
Wrap
Text File
|
1995-07-25
|
67KB
|
1,651 lines
LLLLIIIIBBBBEEEERRRRAAAATTTTIIIINNNNGGGG TTTTHHHHEEEE WWWWOOOORRRRLLLLDDDD ((((MMMMaaaaddddeeee SSSSiiiimmmmpppplllleeee))))
Stan Shebs
Department of Computer Science
University of Utah
_A_B_S_T_R_A_C_T
This is an in-depth document on version 5 of
the _x_c_o_n_q family of programs. Version 5 is quite
different from earlier versions; players familiar
with those should read everything in here, espe-
cially the section on important changes. All
aspects of play are covered. Details on customi-
zation may be found in a companion document.
_W_a_r _i_s _a _m_a_t_t_e_r _o_f _v_i_t_a_l _i_m_p_o_r_t_a_n_c_e _t_o _t_h_e _S_t_a_t_e; _t_h_e
_p_r_o_v_i_n_c_e _o_f _l_i_f_e _o_r _d_e_a_t_h; _t_h_e _r_o_a_d _t_o _s_u_r_v_i_v_a_l _o_r _r_u_i_n. _I_t
_i_s _m_a_n_d_a_t_o_r_y _t_h_a_t _i_t _b_e _t_h_o_r_o_u_g_h_l_y _s_t_u_d_i_e_d. -- _S_U_N _T_Z_U (_c_a
_4_0_0 _B_C)
Welcome to _x_c_o_n_q, a chance for you to free the world from
domination by evil empires. It is similar to previously
distributed empire-building games, but with many more
features. The same basic game is available with several
different interfaces. _X_c_o_n_q is a fully X-based multi-player
game, allowing almost any combination of human and machine
players, and opening up remote X windows as necessary.
There is also a restricted variant _c_c_o_n_q that needs the
curses terminal package only, but allows only one human
player.
In the standard game, you start with one city and no
knowledge of the world beyond your immediate vicinity. You
must then explore, contact, and win wars against all the
other players, who are trying to do exactly the same things
to you! This is made harder by the limited information that
the game supplies; except for the vicinity of your own pos-
sessions (and for certain type of units), the entire view is
out-of-date, and you won't see enemies until they're close
by.
The "standard game" is played on a small (usually 60x30
hexes) randomly generated map, against one machine player.
Your first city will automatically start building your first
September 10, 1993
- 2 -
military unit (usually infantry). When it is ready, the
starting city will be overwritten by a picture of the unit,
which is itself surrounded by a box-shaped cursor (the "unit
cursor"). The mouse (or standard Unix direction keys) may
then be used to designate any location for that unit to move
to. This movement may take several turns, or the unit may
stop before it gets there, usually because it is adjacent to
something unfriendly. To attack, just direct the unit to
move into a hex that shows another unit, and see what hap-
pens (flashes, and maybe a notice at the top of the screen).
When you capture some kinds of units (usually cities), _x_c_o_n_q
will ask you what sort of units you want that unit to pro-
duce; '?' will display the possibilities.
In general, '?' will always work. When typed during normal
movement, you will get a series of help screens, including
commands, news, and unit characteristics. (This info may be
written into printable files if the interface doesn't have
the screen space necessary.)
The foregoing is sufficient to play - just jump in and go!
After a few games, it should be clear what your units can
and cannot do. The game will end automatically when your
opponents are no longer capable of winning (either they have
nothing left or they have given up). The following sections
contain many boring details, and should be referred to for
answers to questions.
_D_E_F_I_N_I_T_I_O_N_S _O_F _T_E_R_M_S
An xconq game involves several _s_i_d_e_s, each of which has a
human or machine player associated with it. Sides may be
enemies, allies, or neutral with respect to each other,
often start out in a hexagonal _c_o_u_n_t_r_y. A side owns a
number of _u_n_i_t_s, which includes the cities and the armed
forces of that side. Units may also be _n_e_u_t_r_a_l, and belong
to no side (this is different from being on a neutral side).
Units may be inside other units, in which case the one
inside is in _o_c_c_u_p_a_n_t, and the other is a _t_r_a_n_s_p_o_r_t (even if
it can't move). Units always have _o_r_d_e_r_s that they follow,
even when they appear to be under manual control. There are
also _s_t_a_n_d_i_n_g _o_r_d_e_r_s that get passed to occupants automati-
cally. The game is divided into a number of _t_u_r_n_s, during
which each side gets to move some or all of its units. All
the action happens over a _m_a_p of a real or imaginary world
that is divided into hexagonal shapes usually called _h_e_x_e_s.
Each hex has a _t_e_r_r_a_i_n assumed to cover the entire hex. In
some games, hexes also have a _p_o_p_u_l_a_c_e belonging to some
side. Terrain on the map can produce _r_e_s_o_u_r_c_e_s, which are
natural items ranging from water and food to gold and
weapons; resources being carried by a unit are also called
_s_u_p_p_l_i_e_s. _S_c_e_n_a_r_i_o_s are predefined games that set up maps,
sides, units, and _w_i_n/_l_o_s_e _c_o_n_d_i_t_i_o_n_s, which define the cir-
cumstances under which one or more sides win or lose in the
September 10, 1993
- 3 -
scenario.
The numbers and kinds of units, resources, and terrain are
not built in; they are defined by a historical (or ahistori-
cal!) _p_e_r_i_o_d. This means that the following sections will
be somewhat vague on specific units and behaviors, since the
information applies to times ranging from Ancient Greece to
Star Wars. Later sections will describe some of the periods
that have been developed so far; in addition, complete
online help is available on the period in effect.
_T_H_E _W_O_R_L_D
_G_e_o_g_r_a_p_h_y _d_e_f_i_n_e_s _t_h_e _b_a_c_k_g_r_o_u_n_d _t_o _c_o_n_f_l_i_c_t. _G_o_l_d
_m_i_n_e_s _a_r_e _u_s_u_a_l_l_y _i_n _t_h_e _m_o_u_n_t_a_i_n_s, _f_a_r _f_r_o_m _t_h_e _s_e_a.
_I_s_l_a_n_d_s _t_e_n_d _t_o _b_e _l_e_f_t _a_l_o_n_e, _u_n_l_e_s_s _t_h_e_y _a_r_e _o_n _a _d_i_r_e_c_t
_p_a_t_h _s_o_m_e_w_h_e_r_e _e_l_s_e. _A _s_e_a_c_o_a_s_t _t_o_w_n _c_a_n _b_e _s_t_r_a_t_e_g_i_c_a_l_l_y
_u_s_e_l_e_s_s _i_f _i_t_s _a_p_p_r_o_a_c_h _i_s _t_h_r_o_u_g_h _s_h_a_l_l_o_w _w_a_t_e_r. _A_t_t_e_n_t_i_o_n
_t_o _t_e_r_r_a_i_n _a_n_d _i_t_s _e_f_f_e_c_t _o_n _o_n_e'_s _u_n_i_t_s _c_a_n _m_a_k_e _t_h_e
_d_i_f_f_e_r_e_n_c_e _b_e_t_w_e_e_n _w_i_n_n_i_n_g _a_n_d _l_o_s_i_n_g.
The world map on which you play is a cylinder of variable
height and diameter. Although it is always displayed as a
rectangle, you can actually circumnavigate the world. The
most northerly and southerly rows of hexes are out of
bounds. Sizes can range from 20x20 "quicky" maps to the
Earth at 1 degree resolution between 60 north and 60 south -
no less than 360 by 120 hexes! When starting up, you have
the choice of several maps of real areas, depending on the
period, or by default you get a randomly-generated 60x30
map. You can get other sizes from about 10x10 up to whatever
your machine's memory can hold, by using the ----MMMM option on
the command line. The ----mmmm command line option loads a named
map, and the ----xxxx option may also offer a menus of maps to
use. Predefined maps usually have their own documentation,
which is displayed on one of the help screens.
Each individual hex of the world contains one kind of ter-
rain, which is assumed to more-or-less cover the entire hex.
The exact set of terrains depends on the historical period;
the set below is from the standard period, and is actually
shared by many periods. Monochrome _x_c_o_n_q uses icons for
each type of terrain, which cannot possibly be described
verbally, so use the help commands to decipher them.
Sea (dark blue) is assumed to be deep enough for any
ship. Armies can't walk on water.
Shallows (light blue or cyan) include shoals, reefs,
rivers, and any other sort of shallow water. They res-
trict movement of ships and may entirely prevent pas-
sage of the largest ships.
September 10, 1993
- 4 -
Plains (light green) are generally flat and hospitable
areas. They usually offer no impediments to movement.
Forest (dark green) is dense forest or jungle, and may
hinder movement for some kinds of units.
Swamps (gray) are half water and half land, and impass-
able to almost everybody.
Desert (yellow) ranges from Saharan sands to Sonoran
cacti. It is always inhospitable but fast to move
through - think of armor in North Africa.
Mountains (brown) are relatively barren and at higher
elevation, thus are also inhospitable to troops.
Ice (white) is deep snow, ice, and glaciers. Only spe-
cially equipped ground units can pass over it, although
most aircraft can fly over.
Vacuum (black) is outer space, included for the purpose
of doing futuristic periods.
Each hex is adjacent to six others, and there is no special
border to cross. By default, hexes represent areas about
100 km on a side, although many maps have larger or smaller
scales.
Randomly generated maps vary in their "roughness", and in
the percentages of each kind of terrain. These properties
also depend on the period, and it is worthwhile to have a
general idea of the values. Percentage coverage is simple
(for instance, the earth is 70% covered by water), but
roughness is more subtle; essentially the "jagginess" of the
terrain. Very rough terrain has lots of sharp peaks and
small islands, while smooth terrain has large flat con-
tinents.
SIDES
_P_o_l_i_t_i_c_s _p_r_o_v_i_d_e_s _t_h_e _c_o_n_t_e_x_t _f_o_r _w_a_r; _t_h_e _w_a_r _b_e_i_n_g _a
_r_e_s_u_l_t _o_f _f_a_i_l_e_d _p_o_l_i_c_y. _T_h_e _l_e_a_d_e_r _o_f _a _c_o_u_n_t_r_y _i_s _f_a_c_e_d
_w_i_t_h _t_h_e _p_r_o_b_l_e_m _o_f _a_c_h_i_e_v_i_n_g _c_e_r_t_a_i_n _g_o_a_l_s, _e_i_t_h_e_r
_e_x_t_e_r_n_a_l_l_y- _o_r _s_e_l_f-_i_m_p_o_s_e_d. _D_i_p_l_o_m_a_c_y _c_a_n _s_o_m_e_t_i_m_e_s _a_c_c_o_m_-
_p_l_i_s_h _t_h_e _d_e_s_i_r_e_d _o_u_t_c_o_m_e, _a_n_d _i_s _m_u_c_h _c_h_e_a_p_e_r _t_o _b_o_o_t.
_W_h_e_n _i_t _f_a_i_l_s, _o_n_e _c_o_u_n_t_r_y _o_r _a_n_o_t_h_e_r _d_e_c_l_a_r_e_s _w_a_r, _a_n_d _a_n_y
_a_l_l_i_a_n_c_e_s _i_m_m_e_d_i_a_t_e_l_y _b_r_o_a_d_e_n _i_t_s _s_c_o_p_e. _D_e_c_l_a_r_i_n_g _p_e_a_c_e
_a_g_a_i_n _i_s _m_u_c_h _m_o_r_e _d_i_f_f_i_c_u_l_t...
Sides in the game can be allies or enemies in various combi-
nations. Any two sides can form a formal alliance; human
players do it by sending the message "alliance" to each
other using the message command (see below). Machine
players are "aware" of their relative incompetence, and will
September 10, 1993
- 5 -
usually ally with each other (except in the case of a
machine player attached to a display, so as to facilitate
debugging). Players may become neutral or declare war by
sending the messages "neutral" and "war" to another side.
Scenarios may sometimes set up particular patterns of alli-
ances, although there is nothing to prevent the players from
changing them around during the game. If all the sides left
in a game are allied, then it automatically ends.
Some displays distinguish alignments by using the same
colors for allies as for yourself, while painting neutrals
and enemies in distinctive colors. For others, you just
have to remember who is on whose side.
Names of sides come from a scenario or are randomly gen-
erated from a list of names, depending on period. If the
period doesn't define any names for sides, then the list
will be 100+ contemporary names (including Botswanans and
Peruvians). Players may also rename themselves, using a
command (see below). Since it is usually hard to remember
which player has which name, many mentions of sides include
the display that the side is using (or nothing if a machine
player), or sometimes the number of the side (especially for
input).
When a side loses, for whatever reason, units are either
destroyed or made neutral (depending on unit and period).
In the standard period, infantry is destroyed, while cities
become neutral (thus easy pickings for the remaining players
who get to them the quickest).
Informal alliances frequently happen in games involving more
than two people, so I have a few words of advice. First, an
alliance between two of the players is almost certain in a
three-person game, and inevitably results in the "odd man
out" being quickly defeated. In four-person games, the
alliances should be decided after looking at the map via "-
v", so that one pair is not hopelessly separated. Five or
more players is going to be a free-for-all of formal and
informal alliances. Some scenarios are designed with a par-
ticular number of players in mind; hopefully they will also
have some natural balance.
_U_N_I_T_S
_W_a_r _i_s _b_a_s_e_d _o_n _t_h_e _a_p_p_l_i_c_a_t_i_o_n _o_f _f_o_r_c_e _t_o _t_h_e _o_t_h_e_r
_s_i_d_e, _u_s_i_n_g _w_h_a_t_e_v_e_r _i_s _a_v_a_i_l_a_b_l_e; _f_r_o_m _s_p_e_a_r_s _a_n_d _a_r_r_o_w_s _t_o
_t_h_e _h_i_g_h-_t_e_c_h _e_q_u_i_p_m_e_n_t _a_v_a_i_l_a_b_l_e _a_s _a _s_i_g_n_i_f_i_c_a_n_t _f_r_a_c_t_i_o_n
_o_f _a _n_a_t_i_o_n'_s _G_N_P.
Units can be almost anything: armies, balloons, triremes,
cavalry, battleships, bridges, headquarters, cities. Units
move around, attack other units, produce resources, and
build more units, among other things. Individual units
September 10, 1993
- 6 -
occupy entire hexes, and no other unit can enter that hex
unless it can occupy or be occupied by the unit already
there.
Only some kinds of units can build other units, at a rate
depending on the period, the unit being built, and the unit
doing the building. The first unit that is produced takes
somewhat longer, and the very first unit built by a side can
take even longer (research and development time), but then
succeeding units come out at a constant rate. There is no
memory about production, so switching to a different type
then switching back still incurs the extra startup time.
Most units that do building will do it all the time, and
only stop when explicitly directed to (such as cities),
while others need to be directed to build, and cannot move
while doing so (such as engineers building a base).
Once created, a unit moves according to its orders, and sub-
ject to various constraints - armies can't swim, ships can't
walk, etc. Units can sometimes be disbanded with a command
(depending on the period), by losing them in battle, by run-
ning out of supplies, by being taken prisoner when a unit is
captured, or by garrisoning a captured unit.
Every unit starts out with a number of _h_i_t _p_o_i_n_t_s represent-
ing its strength, and possibly supplies of food, fuel etc
that it carries around. Supplies are used up by movement,
combat, and by just existing, and are created by production
on certain terrain types, or by transference from some other
unit.
There is only one situation under which several units can be
in the same hex at once; if one is a transport of some sort
and the others are its passengers or occupants. The notion
of "transport" and "occupant" is general, and covers
fighters on carriers, ships in port, bombs in bombers, and
troops being led by a general. Occupants board by moving
into the hex occupied by the transport, but will refuse to
go if the transport is full or can't carry that type of
unit. Getting on board takes a number of moves of that
unit; if there are any left, it may move off or take some
other action. Transports can also move over a occupant to
take it on, but only if the transport can move on the ter-
rain that the occupant is on. Occupants always move with
the transport (that's what transporting is all about!), but
may leave at any time if possible, either onto a valid ter-
rain or onto another transport. To debark, just move the
unit off (the cursor indicates that the occupant and not the
transport is to be moved). Usually, you will want to put
the occupant on sentry duty while moving the transport, and
so must wake the occupants up before they can be moved
again.
September 10, 1993
- 7 -
_T_H_E _G_A_M_E
Games may be predefined scenarios, which define the map,
sides, and units, or they may be randomly generated. If
randomly generated, depending on the period, you start with
either a country-full of units or just one, which may or may
not have its production defined already. If you start with
one, the period may also define some neutral units in your
country, which should be captured as quickly as possible.
Sometimes the map will be too small or have the wrong ter-
rain, and then _x_c_o_n_q will fail at placement and exit
instantly. There is not much you can do at that point
except to try again or relax the constraints, perhaps by
reducing the number of sides or increasing the map size.
(This can also be fixed by altering the period - see the
customization document for details.) Since there is a lot
of randomness in placement, second tries are frequently suc-
cessful, although tenth tries usually indicate a real prob-
lem.
A turn consists of several phases, although only one actu-
ally involves player interaction:
Spy PhaseLeakage of information from one side to another.
Disaster PhaseRevolts, surrenders, attrition, and accidents.
Build PhaseConstruction of new units and repair of damaged
ones.
Supply PhaseProduction and distribution of resources.
Movement PhaseAutomatic and manual movement of all units.
Consumption PhaseDetails relating to supply usage during
movement.
During the movement phase, the program iterates through all
units, prompting each side to give orders to any unit that
is awake or becomes awake during the course of its move.
One consequence is that you will not have a chance to change
orders, look around, or do anything else if no unit produces
a unit and no units wake up. This speeds playing but can be
annoying if you get overrun and lose without ever getting a
chance to respond (but do you deserve anything else for pur-
suing a "hands-off" management strategy?). Sides that lose
are automatically cut out of the game. Since one additional
iteration is needed to verify that somebody lost, the final
winner will have to go through an entire turn before the
game will exit (doing the sentry command on everything is
easy and quick).
The game ends when the win/lose conditions have been met;
September 10, 1993
- 8 -
these vary from scenario to scenario. For a randomly-
generated game, the end comes when no mutual enemies are
left, whether by elimination or by peace. Usually this
means that only one side is left alive, but multiple machine
players (not associated with displays - the usual case) are
always allied, and thus may win as a group. This also means
that a single member of the alliance will not resign until
the position of the whole alliance is hopeless; after all,
the WWII Allies included several brigades of Polish troops
after Poland was overrun.
The last player must type a key to close down the windows
(this is so that they will stay up for everybody to look
at). When the game closes down, the winners (if any) will
be listed. If the STATISTICS option has been set by the
installer, _x_c_o_n_q will write a file "stats.xconq" into the
current directory. This file summarizes some crucial
statistics concerning combat performance, losses, and other
miscellany. It is quite useful for rationalizing your humi-
liating defeat!
_D_I_S_A_S_T_E_R _P_H_A_S_E
_W_a_r _i_s _i_n_h_e_r_e_n_t_l_y _r_a_n_d_o_m. _B_o_t_h _m_i_l_i_t_a_r_y _a_n_d _c_i_v_i_l_i_a_n
_u_n_i_t_s _d_e_s_e_r_t, _g_e_t _d_i_s_e_a_s_e_s, _h_a_v_e _a_c_c_i_d_e_n_t_s, _d_e_f_e_c_t, _a_n_d
_s_u_r_r_e_n_d_e_r _w_i_t_h_o_u_t _a _s_t_r_u_g_g_l_e. _T_h_e_s_e _e_f_f_e_c_t_s _c_a_n_n_o_t _b_e _e_l_i_m_-
_i_n_a_t_e_d _c_o_m_p_l_e_t_e_l_y, _b_u_t _c_a_n _b_e _r_e_d_u_c_e_d _b_y _k_e_e_p_i_n_g _o_n_e'_s
_f_o_r_c_e_s _o_u_t _o_f _h_a_z_a_r_d_o_u_s _s_i_t_u_a_t_i_o_n_s _a_n_d _b_y _k_e_e_p_i_n_g _m_o_r_a_l_e _u_p.
Three types of disasters can befall a unit during the disas-
ter phase: revolt/surrender, attrition, and accidents.
Revolts and surrenders are really the same sorts of
occurrence; a unit changes sides spontaneously, perhaps to
neutrality, perhaps to the side of a nearby enemy unit.
During every disaster phase, each unit makes a revolt check.
The revolt chance is a hundredth percentage. When a unit
revolts, it changes to its original side (whatever the unit
started out as - i.e. your initial units will never revolt).
Occupants will either change over or be killed. Any con-
struction will be cancelled, unless the scenario is one in
which construction changes are not allowed.
Surrender only occurs if a unit is capable of capture is
present. The capturing unit does not move. Occupants of
the surrendering unit also change over or die. Chance of
surrender is increased by low unit morale.
The chance of surrender can be greatly increased (depending
on period) by surrounding the unit completely. This
includes naval units for any sea hexes. One of the sur-
rounding units must be capable (even if only a small chance)
of capturing the unit by direct attack. The siege is only
in effect in those turns where the unit is completely
September 10, 1993
- 9 -
surrounded. When the unit surrenders, one of the "capture-
capable" units will be randomly picked to accept the
surrender, and things happen as for a direct assault
(described below). Note that if several sides are surround-
ing the same unit, the selection is still random from among
those sides, as long as the side is an enemy.
Attrition is a "slow death" process applicable primarily to
multi-hp units. It takes away some number of hit points
each time it occurs, and kills units only if they have no
points left. Attrition is also specified in hundredths of a
percent, and depends on unit type and terrain type. Morale
drops by 1 when attrition occurs. A message will be
displayed as well.
Finally, there is a chance for an accident to destroy a unit
instantly and totally. Like attrition, this depends on both
unit and terrain type, and is measured in hundredths of a
percent. If the accident occurs, the unit is killed along
with all occupants. A message will be displayed.
_B_U_I_L_D _P_H_A_S_E
_S_u_s_t_a_i_n_e_d _e_f_f_o_r_t_s _i_n _a _w_a_r _d_e_p_e_n_d _v_i_t_a_l_l_y _o_n _t_h_e
_r_e_p_l_a_c_e_m_e_n_t _a_n_d _r_e_p_a_i_r _o_f _f_o_r_c_e_s _d_e_s_t_r_o_y_e_d _o_r _d_a_m_a_g_e_d _i_n
_c_o_m_b_a_t. _I_n _t_o_t_a_l _w_a_r, _t_h_e _p_r_o_d_u_c_t_i_o_n _b_a_s_e _c_o_n_s_t_i_t_u_t_e_s _a
_c_h_i_e_f _s_t_r_a_t_e_g_i_c _t_a_r_g_e_t, _t_o _b_e _i_s_o_l_a_t_e_d _o_r _d_e_s_t_r_o_y_e_d _i_f _p_o_s_-
_s_i_b_l_e. _R_e_p_a_i_r _o_f _u_n_i_t_s _i_s _a_l_s_o _s_i_g_n_i_f_i_c_a_n_t _s_i_n_c_e _a _b_a_t_t_l_e
_m_a_y _r_e_s_u_l_t _o_n_l_y _i_n _d_a_m_a_g_e, _b_u_t _b_e _s_u_c_c_e_s_s_f_u_l _n_e_v_e_r_t_h_e_l_e_s_s _i_f
_u_n_i_t_s _m_u_s_t _r_e_t_i_r_e (_a_s _a _c_h_e_a_p_e_r _a_l_t_e_r_n_a_t_i_v_e _t_o _n_e_w _p_r_o_d_u_c_-
_t_i_o_n). _H_i_s_t_o_r_i_c_a_l_l_y, _b_a_t_t_l_e _d_a_m_a_g_e _h_a_s _r_e_s_u_l_t_e_d _i_n _t_h_e _t_e_r_-
_m_i_n_a_t_i_o_n _o_f _a_n _e_n_t_i_r_e _c_a_m_p_a_i_g_n.
During the build phase, units construct new units and repair
damaged occupants (or themselves).
Construction is straightforward; the schedule is decremented
once/turn. When it has counted down to zero, the unit is
created, and placed either as an occupant of the builder, or
the builder is made to occupy the new unit. If neither
alternative works (perhaps because the builder is full
already), then completion is postponed, and attempted on the
next turn. This will be repeated indefinitely. If the new
unit cannot be placed at all, it is thrown away. If the
period specifies that the builder is to guard the new unit,
then the builder will be assigned to garrison the new unit,
and is destroyed.
Repair happens automatically if the damaged unit contains or
is contained by another unit capable of repairing, or if the
unit can repair itself. The repair rate is depends on both
the repairer and repairee, and can happen no faster than one
hp/turn.
September 10, 1993
- 10 -
_S_U_P_P_L_Y _P_H_A_S_E
_T_h_e _A_l_l_i_e_s _f_l_o_a_t_e_d _t_o _v_i_c_t_o_r_y _o_n _a _s_e_a _o_f _o_i_l. -- _L_O_R_D
_C_U_R_Z_O_N.
Resources themselves are basically inanimate material that
come in varying amounts and are governed by conservation
laws. They can be produced, moved around, and consumed dur-
ing various activities. Resources originate either as sup-
plies carried by units at the outset, or more typically,
through production by units. Production rate depends on
unit, resource, and terrain types, and is unaffected by side
changes, combat, or anything else. Produced resources go
into the producing unit's storage.
Excess production is discarded, unless it can be unloaded
into the producer's occupying units, or distributed to
nearby units via _s_u_p_p_l_y _l_i_n_e_s. Supply lines automatically
exist between units that are close enough (as decreed by the
period), and there is no need for explicit manipulation.
Units consume their supplies, both in the course of
existence, and by motion/combat. The rate depends on period
and unit type; it consists of an overhead consumed each turn
without fail, and consumption for each hex of movement. The
total is a max, not a sum, since units with a constant con-
sumption rate are not likely to need additional supplies to
move (consider foot soldiers who eat as much sitting around
as they do walking). Supplies may also be consumed for pro-
duction and repair, again depending on period and unit
types, but this consumption happens during the build phase.
Consumption is not affected by the situation of the consum-
ing unit; armies in troop transports eat just as much as
when in the field.
Supply line length depends on the period and the units on
both ends, but is not affected by the intervening terrain.
Supply redistribution is managed by logistics experts, who
are ignorant of the war effort and seek only to even every-
thing out. The redistribution method is rather adhoc; units
try to get rid of all their excess supply, and try to take
up supply from other units within supply range. Each direc-
tion is controlled independently, so for instance airplanes
can get automatically refueled from a nearby city, but not
from each other. No unit will transfer all of its supply
via supply lines. Normally units in the same hex can
exchange supplies, but some periods can disable this
behavior, so that explicit transfer using the give and take
commands is always necessary.
_M_O_V_E_M_E_N_T _A_N_D _C_O_M_B_A_T
The movement phase is the one in which all the action hap-
pens. At its outset, the phase computes the number of moves
September 10, 1993
- 11 -
available to each unit. This value is essentially the max-
imum of the unit's moves on each type of terrain. The move-
ment phase continues until all these moves have been
expended in some way or another.
Some periods may define a small chance of random movement,
in which the unit moving actually goes in some other direc-
tion than that intended. This is a potentially dangerous
occurrence, since the unit will be destroyed if the hex is
impassable or contains another unit (whether or not the
other unit can take the moving one as an occupant).
All combat occurs during the movement phase. Battles happen
when one unit attempts to move onto a hex occupied by an
unfriendly unit. In most periods, each unit attacks the
other equally well, but if "counterattack" is not enabled,
then the defender just has to sit and take the punishment.
The outcome is determined independently for each unit, based
on a probability table; this means that both draws and
mutual damage/destruction are possible. The odds are the
same whether a unit is attacking or being attacked. Ammuni-
tion may be expended by each unit in each combat - if the
ammo is gone, then the attacker will not attack and the
defender cannot defend itself. The results are announced
both by a message and by some flashes on the screen (the
size of the flash corresponds to damage seriousness). Dam-
age is assessed using hit points, and if the hit points are
zero, the unit is destroyed, along with any occupants. Typ-
ically armies have only one hit point each, so they are des-
troyed if hit. Units with multiple hit points may be _c_r_i_p_-
_p_l_e_d if their hit points drop below a period-specified
level. Crippled units move more slowly (in proportion to
their damage), have reduced transport volume, cannot repair
anything, and do not make progress on any construction. The
final outcome of combat depends on whether the defender was
destroyed. If so, the attacker will move into the
defender's position (if possible), otherwise no movement
will happen.
If a unit is hit sufficiently hard, that is considered a
"nuke" and you get more spectacular visual effects, plus the
hex is converted into desert or something else desolate.
Some units are capable of capturing other units, with a pro-
bability depending on the types of both units involved. If
the capture attempt is successful, the capturer will move
into the hex if possible, either as occupant or transport.
In some periods, the capturer may be all or partially dis-
banded, to serve as guards. The regular attack as described
above always happens first.
September 10, 1993
- 12 -
_O_R_D_E_R_S
_A _p_e_r_e_n_n_i_a_l _f_e_a_t_u_r_e _o_f _t_h_e _h_i_g_h_e_s_t _l_e_v_e_l _o_f _c_o_m_m_a_n_d _i_s
_i_t_s _i_n_h_e_r_e_n_t _c_o_m_p_l_e_x_i_t_y. _A_l_t_h_o_u_g_h _t_h_e _u_s_e _o_f _s_u_b_o_r_d_i_n_a_t_e_s
_r_e_d_u_c_e_s _t_h_e _b_e_w_i_d_e_r_m_e_n_t _s_o_m_e_w_h_a_t, _t_h_e _c_o_m_m_a_n_d_e_r-_i_n-_c_h_i_e_f
_m_u_s_t _s_t_i_l_l _k_e_e_p _i_n _m_i_n_d _h_u_n_d_r_e_d_s _o_f _a_p_p_a_r_e_n_t_l_y _u_n_r_e_l_a_t_e_d
_f_a_c_t_s; _t_h_e _s_t_a_t_e _o_f _t_h_e _w_e_a_t_h_e_r, _t_h_e _p_a_s_t _p_e_r_f_o_r_m_a_n_c_e _o_f
_u_n_i_t_s, _t_h_e _c_u_r_r_e_n_t _g_o_a_l_s _o_f _t_h_e _w_a_r, _a_n_d _m_a_n_y _o_t_h_e_r _t_h_i_n_g_s.
_I_t _i_s _v_e_r_y _i_m_p_o_r_t_a_n_t _t_h_a_t _l_o_w_e_r-_l_e_v_e_l _u_n_i_t_s _b_e _a_b_l_e _t_o
_o_p_e_r_a_t_e _o_n _t_h_e_i_r _o_w_n _a_s _m_u_c_h _a_s _p_o_s_s_i_b_l_e.
Although units have been said to "move", in actuality they
follow orders, some kinds of which specify movement. When
you are moving a unit hex-by-hex, it is following the order
"Awake", which just means that every turn it asks what to do
next. There are many kinds of orders. Some, such as move-
ment in a given direction, or to a given place, take parame-
ters, but all take a repetition, which tells for how many
turns the unit will carry out the order. (For some orders,
the repetition is not particularly meaningful, and is
ignored.) Repetition is always specified as a prefix numeric
argument to commands.
Orders that a unit can do include:
Awake ask for a movement or other command.
Sentry sit at the present location as long as the repeti-
tion says.
MoveDir move in the given direction.
MoveTo try to move to the given location.
FollowCoastattempt to follow a coastline.
FollowLeadermove towards another given unit (which must be
one of your own).
Patrol go back and forth between two points.
Most movement commands just give these orders to the unit
currently being prompted about. In addition, a unit may be
given "standing orders", which will be passed to any unit of
a particular type entering or produced in that unit. This
is useful for a variety of purposes, such as staging fighter
planes up to the front lines or sending ships out on stan-
dard patrols.
_T_H_E _D_I_S_P_L_A_Y
_A_l_l _w_a_r_f_a_r_e _i_s _b_a_s_e_d _o_n _d_e_c_e_p_t_i_o_n. -- _S_U_N _T_Z_U
When a game is started up, it opens a number of windows, of
September 10, 1993
- 13 -
which the most important is the area map (which therefore
gets the largest window). Above the area map are several
windows for status and notifications, and next to those is a
turn counter and a list of all sides in the game. The middle
right side has a list of all unit types, used for statistics
display, while the lower right-hand corner has a map of the
world (if the display is sufficiently large).
All of the _x_c_o_n_q windows are actually subwindows of a main
window with a patterned background you can see here and
there. You can iconify and move the main window, and the
subwindows will keep their relative positions. The largest
of these is the map, which is a (typically) 30x30 section of
the world in full detail. The view is scrolled around as
necessary (remember that the world is cylindrical).
To the right and down, you see a map of the whole world.
This view is like the close-in map, but units and units are
rendered as solid blobs, since the world is too large to
permit any detail. To assist in matching up the two dif-
ferent views, the world map includes an outline box indicat-
ing the position of the close-in view.
Three text displays are stacked at the top of the screen.
The uppermost is about ten lines of notices about various
occurrences, each prefixed by the number of the turn in
which it was issued. The display scrolls. The next four
lines are an information window that summarizes the status
of the unit or unit at the current cursor position. It can
display info about enemy things also, but of course the
amount of information is less. Finally there is a one-line
prompt window just above the map, in which all questions and
prompts appear.
The list of sides playing appears in the upper right corner.
Sides that have already lost appear with a line through
them, while the currently moving side has a "*" next to it.
Your own side name is highlighted or inverted. The name of
the side, its host (if any), and the number of that side are
shown. On color displays, the color of the number indicates
the alignment of that side.
The X interface draws the area map as a number of hexagonal
shapes with icons for units superimposed. Unknown territory
is black. Your own possessions appear in black, neutral
units in gray, and all enemies in red. If there is more
than one enemy side, they are distinguished by the number of
their side in the upper right corner of the icon. Not all
enemy units will be visible; the chance of seeing one may be
very low, or depend on viewing with the right type of unit.
Monochrome screens display enemies and neutrals as inverted
from your own appearance, and all enemy units/units have
numbers, to distinguish them from the neutral units.
September 10, 1993
- 14 -
The curses interface displays each hex as two characters
side-by-side. Terrain is a character representing the ter-
rain, as are units. The second character in a hex is either
the side number of an enemy, or an apostrophe for neutrals.
As mentioned previously, the view is a record of what has
already been seen, but is not updated except in the immedi-
ate vicinity of your own units and units. In multi-human
games, all screens will be kept up-to-date simultaneously,
so that persons waiting for their turns can see enemy units
moving around, units change hands, and so forth.
_I_N_P_U_T
Input may be supplied both from the mouse and the keyboard.
Moving the mouse cursor to a screen position and clicking
either button has the effect of issuing MoveTo orders to the
current unit, which will be carried out until successful.
There are two exceptions. The first is that if the mouse is
on the unit itself, the unit sits where it is until the next
turn (same as the ' ' command below). If the desired new
position is adjacent, the unit will unconditionally move
there - this is useful for attacking enemies. At present,
there is no special meaning attached to particular mouse
buttons.
As an alternative to using the mouse, the standard direc-
tions (h = West, l = East, y = NW, u = NE, b = SW, n = SE)
can be used to specify movement. Uppercase versions of
these makes the unit move forever in that direction. Letter
directions are really only of use when the mouse fails, or
for diehard Unix game players for whom the direction keys
have been permanently wired in the brain! Note that in a
hexagonal system, 'j' and 'k' are not meaningful.
Any command may be prefixed by a single numeric argument
(which may be positive or negative). Not all commands will
use this number, while others need a number to know how
often to repeat an order, or perhaps for some other reason.
The "current unit" is the one being prompted about, while
the "main unit" is the one occupying the hex itself (as
opposed to its occupants).
Commands to give units orders typically default to a repeti-
tion of 100 turns (In some cases, this is meaningless, as in
moving to a place):
s Sentry; the current unit "goes to sleep", only wakes
up by explicit command or when an enemy pops into view
(the enemy unit won't necessarily be adjacent, if the
unit on sentry duty can see far-off hexes).
September 10, 1993
- 15 -
w Wake up; the unit's orders will be erased (whatever
they were) and it will ask about its next order (not
always immediately). This command interprets an argu-
ment as a radius for the effect of waking up; for
instance, the default of 0 means to wake only the unit
itself, 1 means to wake up adjacent units as well, 15
will wake up a screenful of units, and 999 will usu-
ally wake all units.
W Wake all; both the unit and all its occupants will be
woken up, as well as all of their occupants, recur-
sively. The command is otherwise identical to 'w'.
Space Sit; unit goes on sentry duty for exactly one turn,
and will ask for a move in the next turn. Useful for
waiting one or two turns.
r Return; unit returns to nearest transport by shortest
route. It will not return to transports with no room
or no supplies. Most useful for aircraft, but works
with any unit.
m Move to a position; this is equivalent to mouse click-
ing, but can be used with mouse-less interfaces or to
move further than one screen width. You will be
prompted to do movement commands (either mouse or key-
board), then can use the space bar to designate the
final destination.
f Follow leader; follow another unit. The program will
ask you to designate a unit to be followed, which must
be one of your own. The interaction is identical with
that for 'm'. Each turn the unit either attempts to
move towards its given leader, and sits if it is
within a couple hexes of the leader. Units will not
follow themselves.
F Follow coast; follow a coast line. This can be
applied to any unit, although the unit will immedi-
ately wake up again if it is not next to some sort of
terrain that it cannot move into. The command will
prompt for a standard direction to decide how to
start, then a contour-following algorithm will con-
tinually try to keep the unit adjacent to impassable
terrain (thus armor might use this command to go
around a mountain range or forest). Because the ter-
rain is in discrete hexes, it is possible for the unit
to get confused, but that's life.
Z Patrol; set the current unit to go back and forth
between two points. One point is the unit's current
position, and the other will be prompted for. The
roundtrip will be repeated for the number of times
designated by the command's argument.
September 10, 1993
- 16 -
Commands for modes. There are only two modes defined at
present: move mode (the default) and survey mode. Most com-
mands work the same in both modes.
z Survey mode; toggle into/out of survey mode. In sur-
vey mode, movement pushes a cursor and allows you to
look at things. The other commands are still avail-
able; for instance, you can give a unit new orders or
to set unit production.
Commands for general manipulation of units:
d Delay move; unit's movement is delayed until all your
other units have been moved, then it will be prompted
for again. Useful in crowded situations. Delay can
be used on any number of units any number of times
during a turn.
P Set unit production; will ask for a type of unit (if a
choice possible) and then schedule construction for a
unit of that type. Any partial production will be
discarded.
I Idle; cancel production for the given unit and leave
it idle for a while Default is 100 turns, argument to
command overrides.
C Call unit by name; prompts for a string by which
current unit will be referred to. If string is empty,
unit name will be removed. If this command is done
when the cursor is on an empty hex, the string will
become the new name of the whole side instead.
D Disband; unit disbands and disappears from game. Not
all units can be disbanded; for instance, most periods
will not allow the voluntary destruction of a city.
If an occupant is disbanded, then its transport will
get any available resources, both those held as sup-
plies and any used in making the disbanded unit (pos-
sibly not all, depending on the period's "efficiency"
parameter).
a Cycle through occupants; this can only be used in sur-
vey mode, and allows examination of each occupant and
its suboccupants. The order of traversal is depth-
first, and cycles through all units in the hex repeat-
edly.
x Mark a unit; used with embarkation, below. Only one
unit is ever marked at any one time.
e Embark; put the current unit onto a random transport
in the same hex. This is useful when you don't want
to move transport or unit out just for the purpose of
September 10, 1993
- 17 -
boarding. If the marked unit is in the same hex, it
will be used as the transport.
g Give supplies; transfer all types of supplies from the
current unit to its transport, if there is one. The
default is to try to fill up the transport if possi-
ble. If an argument is supplied, it means to transfer
exactly that quantity of each resource type. If the
current unit is low on some type, then it will
transfer half of what was requested. (Repeating the
command transfers half again, and so forth.)
t Take supplies; transfer all types of supplies to the
current unit from its transport, if there is one. The
default is to try to fill up the current unit, or to
interpret the argument as the quantity to take. If
the transport is low, then it will only transfer half
of what was requested.
O Set standing orders; will ask for type of unit to
which standing orders will apply, then goes into a
"teach mode"; the next input will saved as an order
rather than being applied to some unit. When any unit
of the appropriate type enters the unit with the
standing order, it will be given those orders and
carry them out. There is no way to cancel standing
orders at present, but occupants can be set to wake up
during entry.
G Give unit; give the current unit to the side speci-
fied by the argument. If the side is invalid, then
the unit is made neutral. Not all unit types can be
given away.
Commands for side manipulation:
c Center; the list of units is sorted so that the one at
the current cursor will move first, and others move in
concentric circles outward. This is useful for con-
centrating on one particular area and reducing the
amount of map redrawing.
M Message; send a message to another side. The side is
specified by giving its number as a prefix to the com-
mand; if the number is not the number of a side, then
your message will be broadcast to all sides (including
yourself). You may type in a message up to the length
of the prompt window. Backspacing is available. When
a newline is entered, the message is sent immediately
to the destination. Specially recognized messages
must be typed exactly, with no other words or charac-
ters in the message:
September 10, 1993
- 18 -
war Declare war. Only one side need do this. This
involves all allies on both sides immediately.
neutral Declare neutrality. Both sides must send this
message to each other.
alliance If two sides send this message to each other,
they become formal allies. The display changes
to reflect this, as do things like wakeups, etc.
All sides in the game will hear about the alli-
ance.
briefing Sends the view of all of your units to the other
side. Useful for allies, as well as to convince
a victim that further resistance is hopeless.
Of course, the victim's position might not be so
hopeless after all, in which case you've given
away all your secrets!
Commands for game control.
X Resign; resign from the game, (asks for confirmation
first). The effect is the same as losing.
Q Quit; terminate the game for everybody (asks for con-
firmation first). Note that although this can be used
even in multi-human games, applying it without prior
consent of the other players is definitely anti-
social!
S Save game; record the game state into a file and exit
(asks for confirmation first). The saved game is
ASCII and unprotected, so it's possible to "check-
point" games and engage in other kinds of cheating.
The game exits once it has been saved. To restart,
start up the program without any command line argu-
ments, and in the directory where the save file is
located. If players are specified on the command
line, then they override the saved player data. This
is one way to switch sides; for instance, saving from
"xconq" and restarting with "xconq -r -e 1 $DISPLAY"
has the effect of you switching sides with the
machine.
A Add player; add a new player to the game (not imple-
mented yet).
o Options; set various options. Each option is a single
character. Options at present include:
g Graph; toggle between text and bar graph
displays about the current unit's supplies, hit
points, etc.
September 10, 1993
- 19 -
d Display mode; cycle between four different color
display techniques. The curses interface also
has two display modes (one or two terrain chars
per hex), but you still have to cycle between
four modes.
i Invert; invert foreground and background colors
everywhere (monochrome only).
w Width; set the width of the map display to be
the value of the argument. This is measured in
hexes.
h Height; set the height of the map display to be
the value of the argument. This is measured in
hexes.
n Notices; set the number of notice lines at the
top of the screen.
r Robot; convert yourself into a machine player.
This asks for confirmation, and is not reversi-
ble! However, if there are no other human
players, ^C is re-enabled, so at least you can
terminate the program.
m Monochrome; This has the bizarre behavior of
converting a color display into its monochrome
equivalent. Actually intended for debugging,
but pretty flashy if you're bored.
Information commands.
? General help; show a sequence of help screens, start-
ing with a list of commands, then a display of icons,
then any news, then general info about the period,
then the characteristics of each unit (as for '='
below). You may page back and forth through the
screens. This general help is available in both move
and survey modes. Some specialized prompts (such as
for unit type) will also recognize '?', but will only
supply more details about possible answers to the
prompt.
/ Identify; display a short phrase indicating what is
being seen in the hex at the current cursor position.
This works in all modes, and is useful for deciphering
unusual colors or icons.
= List the characteristics of a type of unit. It will
prompt for the type, then format all the period-
specific details into a semi-readable summary. To get
a hardcopy of this, use 'p'.
September 10, 1993
- 20 -
p Print; dump all the characteristics of all unit types
into a file "parms.xconq". This file may be printed,
and is very useful for learning about a period. It
will include designer's notes about the period which
cannot otherwise be obtained. Also print the current
view, and a list of the commands.
v View current unit; display a flash that should be
bright enough to catch the eye and make it easier to
see where the current unit is.
V Version; display the current version and other useless
information. Be sure to include the version number
when reporting bugs.
^R, ^LRedraw the screen. Redrawing happens automatically
most of the time. Keep in mind that _x_c_o_n_q is a single
program, despite opening multiple screens, and
attempts to redraw may be ignored for awhile.
Additional commands are available for building scenarios,
and are described in the customization document.
_P_E_R_I_O_D _H_E_L_P
The help screens describing unit characteristics include an
enormous amount of information. In fact, a period that
utilized the full range of capabilities would be too compli-
cated to play, even as a computer game. As a result, the
help screen are rather compact and cryptic. For any single
unit, there are three tables, summarizing the unit's rela-
tionships with resource, terrain, and other unit types. The
numbers in parentheses are default values that fill in any
blank entries.
Resources:
ToBui Amount of resource needed to build the unit.
Prod Amount produced each turn under best conditions.
Store Amount that can be carried around.
Eats Minimum amount consumed during a turn.
ToMov Amount consumed by moving one hex.
Hits Amount needed to hit another unit.
HitBy Amount needed to be hit by another unit.
Terrain:
September 10, 1993
- 21 -
Slowed Move penalty for entering hex with the given terrain
type. Default is negative, which prevents movement
entirely. 0 means can move in at maximum speed.
Rand% Chance (in hundredths of a percent) to move randomly
in the terrain.
Hide% Increased difficulty for others to see unit in this
terrain.
Defn% Increased difficulty for others to hit unit in this
terrain.
Prod% Productivity of this terrain for resource produc-
tion.
Attr% Chance (in hundredths of a percent) for attition to
occur.
Acdn% Chance (in hundredths of a percent) for an accident
to occur.
Other units:
Hit% Chance to hit a unit of that type.
Damg Number of hit points of damage done when hit suc-
cessful.
Cap% Chance to capture unit.
Guard 1 if capturing unit converted into garrison.
Pro% Percentage of hit that is prevented from hitting the
unit type that occupies, or decrease in chance of
hit on unit type transporting this unit.
Holds Number of units that can be carried.
Enter Extra moves consumed by entering the transport type.
Leave Extra moves consumed by leaving the transport type.
Mob% Transport mobility when carrying unit type.
Bridg 1 if can attack unit type across impassable terrain.
Build Basic construction time for the unit type.
Fix Time to repair one hit point of damage to the unit
type.
The customization document has additional explanation for
some of these (rather obscure) parameters.
September 10, 1993
- 22 -
_H_I_N_T_S
_G_e_n_e_r_a_l_l_y _i_n _w_a_r _t_h_e _b_e_s_t _p_o_l_i_c_y _i_s _t_o _t_a_k_e _a _s_t_a_t_e
_i_n_t_a_c_t; _t_o _r_u_i_n _i_t _i_s _i_n_f_e_r_i_o_r _t_o _t_h_i_s. -- _S_U_N _T_Z_U
_A_t_t_a_c_k _w_h_e_r_e _h_e _i_s _u_n_p_r_e_p_a_r_e_d; _s_a_l_l_y _o_u_t _w_h_e_n _h_e _d_o_e_s
_n_o_t _e_x_p_e_c_t _y_o_u. -- _S_U_N _T_Z_U
_T_h_e_r_e _h_a_s _n_e_v_e_r _b_e_e_n _a _p_r_o_t_r_a_c_t_e_d _w_a_r _f_r_o_m _w_h_i_c_h _a
_c_o_u_n_t_r_y _h_a_s _b_e_n_e_f_i_t_e_d. -- _S_U_N _T_Z_U
The works of Sun Tzu and Clausewitz say nearly all there is
to be said on strategy in general. _X_c_o_n_q strategy is fairly
close to real strategy.
The most important consideration is to conceal your own
forces and movements as much as possible. Decoys and feints
are worthwhile if they don't draw critcial strength away.
Secondly, don't rush to attack with weak forces. Especially
over long distances, the defender has the advantage. Wait
until you have assembled enough to take and hold a piece of
territory, then allow some extra, just in case.
Make a plan, and have some contingency plans ready as well.
Be ready to take advantage of opportunities.
_P_E_R_I_O_D_S
_X_c_o_n_q starts with one period compiled into it. It can also
read and interpret other periods. Typically the installer
will have built in the period called "standard", for which
the description is included below. Other periods include
Napoleonic times, Ancient Greece, a somewhat silly futuris-
tic period, an even sillier "Star Wars" period, whose sole
reason for existence is to watch death stars blast cities, a
"flattop" period featuring carriers, some simulations of
board games, and more.
The standard period represents units of about 1945, from
infantry to atomic bombs. This is the most familiar, which
makes it easier to play, but also more controversial, since
historians have many conflicting theories about which kinds
of units were most effective. This set has been most influ-
enced by other empire games (thus the greater variety of
ships), and the numbers have been honed by extensive playing
experience at Utah.
Infantry. The infantry division is the slowest of
units, but it can go almost anywhere. It is also quick
to produce. Infantry is the staple of campaigns - a
little boring perhaps, but essential to success.
September 10, 1993
- 23 -
Armor. The armor division is highly mobile and hits
hard. Unfortunately, it is limited to operating in
open terrain - plains and desert. It also takes longer
to produce. Armor can last twice as long in the desert
as infantry. Both armor and infantry can assault and
capture units; they are the only units that can do so.
Fighters. A fighter is a squadron or wing of high-
speed armed aircraft. Their fuel supply can be gotten
only at units, towns, and bases, so they must continu-
ally be taking off and landing. Fighters are not too
effective against ground units or ships, but they eat
bombers for lunch. Fighters are very good for recon-
naisance - important in a game where you can't always
see the enemy moving!
Bomber groups. Bombers are very powerful, being capa-
ble of destroying any unit. Attrition rate in such
activities is high, so they're not a shortcut to vic-
tory! Bomber performance against other units is less
impressive, and of course fighters love to munch on
them. Bomber range is greater, but they are slower,
taking several turns before they must land. They are
also a last-ditch method to escape from a continent if
no seaports are available.
Destroyers. Destroyers are fast small ships for both
exploration and anti-submarine activities.
Submarines. The favorite food of submarines is of
course merchant shipping and troopships, and they can
sink troop transports with one blow. Subs can't be
seen by the other side, although their presence might
be suspected. Subs are always highly vulnerable to
attack by bombers or even fighters.
Troop transports. This is how ground units get across
the sea. They can defend themselves against ships and
aircraft, but are basically vulnerable. They're not
very fast either.
Aircraft carriers. Compensates for the fighter's lim-
ited range by providing a portable airport. Carriers
themselves are sitting ducks, particularly with respect
to aircraft. Fighter patrols are mandatory.
Battleships. The aptly named "Dread Naught" has little
to fear from other units of this period. Subs may sink
them with enough effort, and a group of bombers and
fighters are also deadly, but with eight hit points to
start, a battleship can usually survive long enough to
escape. Battleships are very effective against units
and armies, at least the ones on the coast.
September 10, 1993
- 24 -
Atomic bombs. The Final Solution; but they are not
easy to use. A bomb takes a long time to produce,
moves very slowly by itself, is easily destroyed by
other units, and reduces the range of bombers that
carry it. The plus side is instant destruction for any
unit of any size!
Bases. To simplify matters, this can serve as a camp,
airbase, and port. Bases cannot build units, although
they can repair some damage.
Towns. Towns are the staple of territory. They pro-
duce units at the same rate as cities, but are easier
to capture.
Cities. Cities are very large, powerful, and well
defended. They are basically capital cities, or some-
thing in a comparable range. (New York and San Fran-
cisco are cities, Salt Lake City and San Antonio are
towns.) A city is worth five towns, territory-wise.
Current thinking about optimal strategy for this period
differs. In general, blitzkrieg works, and can win the game
in a hurry. The problem is to muster enough force before
striking. One full troop transport is not enough; the inva-
sion will melt away like ice cream on a hot sidewalk, unless
reinforcements (either air or land) show up quickly. Air
cover is very important. While building up an invasion
force, airborne assaults using bombers and infantry can pro-
vide useful diversions, although it can be wasteful of
bombers. Human vs human games on the default map generally
last about 100 turns, usually not enough time or units to
build atomic bombs or battleships, and not a big enough map
to really need carriers (although bases for staging are
quite useful.)
_C_H_A_N_G_E_S _F_R_O_M _V_E_R_S_I_O_N _1
Aside from the significant changes (hexes, simultaneity,
period descriptions), there are a number of smaller changes
that will affect experienced players:
The command to construct a base is now the same as the
general build command ''''PPPP'''' (since bases are units like
any other).
The random movement command is gone.
The disband command is now ''''DDDD'''' instead of ''''dddd''''.
There are probably others I have forgotten about.
September 10, 1993
- 25 -
_A_C_K_N_O_W_L_E_D_G_M_E_N_T_S
Special thanks must go to Eric Muehle, now at Martin-
Marietta, who has been a tireless source of ideas, advice,
and playtesting. Mohammad Pourheidari, Bob Kessler, Kevin
Deford, Spencer Thomas, Dan Reading, Mark Bradakis, Grant
Weiler, Jed Krohnfeldt, Sandra Loosemore, Jimmy Miklavcic,
Tim Moore, and others at Utah have also endured initial
playtesting, with the apparently endless bugs and mis-
features. Thanks also to Leigh Stoller, who suggested using
X, and to Harold Carr, who suggested the postfix language
for period descriptions.
Since the first release, many many _x_c_o_n_q players around the
net have sent in literally hundreds of suggestions, fixes,
and improvements. Significant contributors include Jim
Anderson at CMU; Jay Scott at Swarthmore, who designed the
"future" period; John Tonry at MIT, who supplied a great map
derived from JPL data; Kurt Hoyt at SEI, who did an X11
port; Julian Onions at Nottingham; Ravi Subrahmanyam at
MCNC; and Joel Rives at Georgia Tech, who is working on a
large period. Chris Peterson at MIT and Tim Moore at Utah
have been essential to the construction and debugging of the
X11 interface to version 5. In addition, A.G. Hirai, Jeff
Kelley, John Shovic, Dave Pare, Michael Lounsbery, Josh
Siegel, Fred Douglis, Cimarron Taylor, and Rick Ledoux have
shared a number of good ideas, although not all of them made
it into this version.
September 10, 1993
